Skip to content

Fix Coverity builds #764

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jun 11, 2025
Merged

Fix Coverity builds #764

merged 2 commits into from
Jun 11, 2025

Conversation

dscho
Copy link
Member

@dscho dscho commented Jun 11, 2025

As of three months ago, the Coverity builds fail.

The reason is most likely the most recent release, 2025.3. Its release notes do not shed any light into the issue (and does not mention that they bundle JDK20 and JDK22 in addition to JRE, because what's better than a single Java installation: three, right?).

My investigation turned up .dll files that are located in Coverity's bin/ directory which have the same name as .dll files in Git for Windows' SDK. As a consequence, the former override the latter and throw off MSYS2's logic to find the MSYS2 root directory given the location of certain .dll files.

This PR, which is a companion of git-for-windows#5672, fixes this issue, and while at it, enhances the Coverity workflow to print out the build log in case of failure.

dscho added 2 commits June 11, 2025 15:02
When I added the Coverity workflow in a56b623 (ci: add a GitHub
workflow to submit Coverity scans, 2023-09-25), I merely converted an
Azure Pipeline definition that had been running successfully for ages.

In the meantime, the current Coverity documentation describes a very
different way to install the analysis tool, recommending to add the
`bin/` directory to the _end_ of `PATH` (when originally, IIRC, it was
recommended to add it to the _beginning_ of the `PATH`).

This is crucial! The reason is that the current incarnation of the
Windows variant of Coverity's analysis tools come with a _lot_ of DLL
files in their `bin/` directory, some of them interferring rather badly
with the `gcc.exe` in Git for Windows' SDK that we use to run the
Coverity build. The symptom is a cryptic error message:

  make: *** [Makefile:2960: headless-git.o] Error 1
  make: *** Waiting for unfinished jobs....
  D:\git-sdk-64-minimal\mingw64\bin\windres.exe: preprocessing failed.
  make: *** [Makefile:2679: git.res] Error 1
  make: *** [Makefile:2893: git.o] Error 1
  make: *** [Makefile:2893: builtin/add.o] Error 1
  Attempting to detect unconfigured compilers in build
  |0----------25-----------50----------75---------100|
  ****************************************************
  Warning:  Build command make.exe exited with code 2. Please verify that the build completed successfully.
  Warning:  Emitted 0 C/C++ compilation units (0%) successfully

  0 C/C++ compilation units (0%) are ready for analysis
   For more details, please look at:
      D:/a/git/git/cov-int/build-log.txt

The log (which the workflow is currently not configured to reveal) then
points out that the `windows.h` header cannot be found, which is _still_
not very helpful. The underlying root cause is that the `gcc.exe` in Git
for Windows' SDK determines the location of the header files via the
location of certain DLL files, and finding the "wrong" ones first on the
`PATH` misleads that logic.

Let's fix this problem by following Coverity's current recommendation
and append the `bin/` directory in which `cov-int` can be found to the
_end_ of `PATH`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is quite helpful to know what Coverity said, exactly, in case it
fails to analyze the code.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho self-assigned this Jun 11, 2025
@dscho dscho marked this pull request as ready for review June 11, 2025 14:02
@dscho dscho merged commit 1e73cc0 into microsoft:vfs-2.49.0 Jun 11, 2025
61 of 62 checks passed
dscho added a commit that referenced this pull request Jun 13, 2025
As of three months ago, the [Coverity builds
fail](https://github.com/microsoft/git/actions/workflows/coverity.yml?query=branch%3Avfs-2.49.0).

The reason is most likely the most recent release, 2025.3. Its [release
notes](https://documentation.blackduck.com/bundle/coverity-docs/page/webhelp-files/relnotes_latest.html)
do not shed any light into the issue (and does not mention that they
bundle JDK20 and JDK22 in addition to JRE, because what's better than a
single Java installation: three, right?).

My investigation turned up `.dll` files that are located in Coverity's
`bin/` directory which have the same name as `.dll` files in Git for
Windows' SDK. As a consequence, the former override the latter and throw
off MSYS2's logic to find the MSYS2 root directory given the location of
certain `.dll` files.

This PR, which is a companion of
git-for-windows#5672, fixes this issue, and
while at it, enhances the Coverity workflow to print out the build log
in case of failure.
dscho added a commit that referenced this pull request Jun 16, 2025
As of three months ago, the [Coverity builds
fail](https://github.com/microsoft/git/actions/workflows/coverity.yml?query=branch%3Avfs-2.49.0).

The reason is most likely the most recent release, 2025.3. Its [release
notes](https://documentation.blackduck.com/bundle/coverity-docs/page/webhelp-files/relnotes_latest.html)
do not shed any light into the issue (and does not mention that they
bundle JDK20 and JDK22 in addition to JRE, because what's better than a
single Java installation: three, right?).

My investigation turned up `.dll` files that are located in Coverity's
`bin/` directory which have the same name as `.dll` files in Git for
Windows' SDK. As a consequence, the former override the latter and throw
off MSYS2's logic to find the MSYS2 root directory given the location of
certain `.dll` files.

This PR, which is a companion of
git-for-windows#5672, fixes this issue, and
while at it, enhances the Coverity workflow to print out the build log
in case of failure.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants